1. Field of the Invention
This invention relates generally to automatic test equipment for electronics, and, more particularly, to instrumentation that is adaptable for simulating, emulating, or testing a wide variety of serial bus types.
2. Description of Related Art
The digital serial link provides a popular way of communicating between electronic portions of a digital system. In a digital serial link, a transmitter sends digital data over a wire, optical fiber, or other transmission medium, to a receiver, which receives and reconstructs the original data. The serial data link can be used to communicate any kind of data, including static information, as well as programming code, control signals, and so forth.
A “serial bus” is a digital serial link that defines a structure for communications (i.e., a medium, encoding, data format, speed, and so forth). Because they communicate using a single data signal, serial busses are popular in applications where it is desirable to reduce the number of wires that interconnect different parts of a system. These applications include long-distance communications, such as digital telephony, applications where it is desirable to minimize weight, such as in airplanes and automobiles, and applications where it is desirable to use small cables having few wires, or small connectors having few contacts.
Serial busses generally involve taking digital data, serializing it, adding content for error detection and correction, if desired, modulating a signal in some way with the data (typically to optimize cost, noise immunity, power, etc.), and transmitting the data over some medium. The reverse process essentially takes place when receiving data. There are a vast number of ways of performing these functions. The large number of standard serial busses, plus the larger number of applications-specific serial busses in use, attests to the flexibility of this approach.
In addition to a single data signal, serial busses may also employ non-data support signals. These signals support the transmission of data but do not actually make up the data being transmitted. These non-data support signals commonly include:                Handshaking Signals—dedicated signals that coordinate data flow, by signaling between a transmitter and receiver that data is ready, that no more data can be accepted, or that a transmission is starting or ending;        Clocks—signals that provide timing information for the data, i.e. they qualify when a symbol on the bus is stable or ready for reception. Clocks may also provide handshaking functions by turning on and off when data is or is not ready for transmission;        Sync Signals—limited-use handshaking signals that indicate the beginning (and sometimes the end) of a data transmission;        Envelope Signals—limited-use handshaking signals that indicate when the data is valid during a transmission.        
It should be noted that wireless transmissions through the air or through space are considered herein to be serial transmissions. Included in our definition of serial busses are those that encode more than one bit of data in a single symbol (the smallest unit of data). A symbol's encoding is by necessity non-binary in these instances, i.e., the bits in one symbol are represented by varying voltage amplitudes, phases, or frequencies. As long as symbols are transmitted via a single signal, a bus transmitting these symbols can qualify as a serial bus.
A myriad of different serial busses is in use today, and many of these have been developed for a single application. Modern aircraft employ hundreds of instances of serial busses and dozens of different serial bus types. So do other large systems, like automobiles, or fixed systems, like nuclear power plants. Different busses often have different ways of encoding data, timing data transmissions, providing signaling and control, providing error detection and correction, and modulating a data signal through a medium. Some busses are unidirectional; others are bidirectional. Some busses are point-to-point, others are multi-drop. Some busses include handshaking, envelope, or sync signals; others encode all of these functions in the serial data stream. Some busses provide only simple data transmission; others include in their definition higher-level functions like response times, collision detection and avoidance, retry on error, and multiple terminal broadcast.
With this wide variety of bus types and features comes a real problem of standardizing the control, test, and maintenance of serial busses. Since serial busses form the spine of many complex systems, observing and controlling serial busses is a primary way of observing and controlling the systems of which they are a part. We have recognized a need for universality in interfacing with different busses and believe that the current state of affairs can be summarized as follows:                Complex systems contain many instances and types of serial busses.        There are hundreds of standard serial busses, and untold numbers of custom serial busses in use today.        It is desirable to control these busses for testing, debugging, and controlling complex systems.        No instrument or circuit of which we are currently aware is able to interface with more than a few variations of busses, nor does any instrument appear to have the performance required to control more than a few types of busses.        Consequently, complex systems commonly incorporate several to dozens of different, independent serial bus interfaces.        Nonstandard busses often require customized interfaces, which require significant time and money to create.We have come to believe that a highly desirable solution to this problem would be a circuit or instrument that could        Control standard serial busses.        Be configured or programmed to control custom serial busses, without the requirement of creating a custom interface.        Be as easy to use as the currently available methods for these applications.        
Currently, techniques for interfacing with different types of busses include (i) using an applications-specific instrument, and (ii) using a serial arbitrary waveform generator. The most common way to control a standard bus, i.e., one having a formal definition that is used in many applications, is with an “applications-specific instrument.” An applications-specific instrument is an instrument or other interface that has been designed specifically to control a particular type of bus. Many such instruments are currently available for popular busses.
Applications-specific instruments are generally able to interface with a limited set of defined variations of a standard bus. For example, TIA/EIA-232 (i.e., RS-232) has multiple commonly accepted operating speeds, word lengths, and operating voltage levels. Most applications-specific instruments for RS-232 include alternate configurations that allow for a limited set of these variations. Although the instruments can select from a predefined set of variations, they do not allow control over the interface in detail. For example, RS-422 is identical to RS-232, except that it uses differential signaling that allows for longer distances and higher transmission speeds. Therefore, an instrument may incorporate both an RS-422 and an RS-232 interface, and allow a user to select one of the two. The instrument would not allow wide-ranging changes to the specification, however.
FIG. 1 is a simplified block diagram of an applications-specific instrument. Data flows in and out of an instrument, which processes it according to a defined bus standard. A few parameters (A, B, and C) can be statically specified to select certain bus characteristics.
The applications-specific instrument provides the advantage of ease of use. Since the instrument was designed to emulate a limited set of busses, little setup is required. The user can concentrate on the data to be sent and received, without being concerned with the bus specification. In addition, the applications-specific instrument provides some quantum of flexibility. If the instrument designer can anticipate multiple possible uses, these can be designed in and the user can select from the available variations. Every additional feature adds cost and complexity, however.
Despite these advantages, the applications-specific instrument is not truly universal. It can only emulate busses that the designer anticipated emulating at the time of design. The more busses that are emulated, the larger and more complex the instrument becomes, until it equivalently becomes several instruments. And whenever an unanticipated variation is introduced, the instrument must be redesigned if it is to emulate the variation. In summary, applications-specific instruments do not provide a universal solution for bus emulation, but they do set a standard for ease of use.
Currently, the best flexibility in generating serial waveforms is obtained using the technique shown in FIG. 2. An arbitrary waveform generator 210, perhaps one that is optimized for serial busses, can be used to generate any serial stream within its performance limits. Similarly, a digitizer 212 can be used to capture a serial bus stream and save it for reconstruction of the digital data. This “Arb/Dig” approach is capable of generating and/or receiving data for a large number of standard and custom serial busses. It also offers the advantage that bus performance can be margined, i.e., parameters like speed, voltage levels, and slew rate can be controlled by varying the source data.
The Arb/Dig approach tends to be difficult to use, however. The serial data must generally be specified and interpreted at the analog waveform level. In addition, this technique is not as flexible as one might expect. Small changes, for example, in the number of data bits per word, can require recreating the entire analog waveform from scratch. Furthermore, this technique generally provides no real-time control. Since data transformation and analysis generally happen during pre- and post-processing from memory, the Arb/Dig approach is not inherently set up for handshaking or other real-time responses. In addition, the operative portions of the Arb/Dig implementation run at the bit rate of the input or output waveform, and thus require a large amount of high-speed circuitry. High speed circuitry translates to higher cost and higher power.
What is desired is a serial bus emulator that is capable of emulating all possible serial buses, standard or custom, within its performance envelope. It should be able to handle handshaking, syncs, clocks, and other control signals. It should be flexible for handling bus variations that are not even developed yet. The serial bus emulator should be as easy to use as a applications-specific instrument, and should be provided in a cost-effective and compact manner.